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ABSTRACT 


During @he period of Time trom Aiweusite ome Chrough Jan-— 
uary 1971 and while employing the TSS/360 Time-Sharing Sys- 
tem at this institution, it was observed by the user 
community that the performance of the system was poor com- 
pared to the previously used time-sharing system - the CP/67 
(version 2, from Cambridge Research Center). For this reason, 
the problem of improving TSS/360 performance was undertaken 
as a thesis project. Specifically, the improvements consist 
of an increase in System performance - responsiveness and 
throughput - by judiciously adjusting the parameters of the 
TSS/260 Table-Driven Scheduler in accordance with the 
Pmelniciples of Balanced-—Core Time and Working Set Size. 

A number of test runs were made, and the results are giv- 
en, employing different schedule tables. A set of benchmark 
programs (or script) were developed and used with these tests 
that were characteristic of a "typical" or "realistic" load 


at this installation. 
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i. SINT RODUGRON 


Since the imitial release of the time=-shared operagine 
oben. os, joer Oclober tog, Senposaeeee has improved 
Significantly with each subsequent release. However, for the 
period from August 1970 to February 1971, the Naval Postgerad— 
uate School converted from the CP/67 time-sharing system to 
the Time-Snared System, TSS/360, and found the new system 
undesirable to the user community in terms of system perfor- 
mamee = responsiveness and throughput. Because of its poor 
performance, TSS/360 was short-lived at the school and was 
never given an opportunity through testing and evaluation 
procedures to indicate its worth and future use as a good 
performance time-sharing utility. 

The objective of the research for this thesis was to 
find ways of improving the performance of TSS/360 at the 
ival Postgraduate -School. 

After having read the available literature on the 
TSS/360 system, it seemed that the key area for study and 
work was the scheduling algorithm. At first a simulation 
model of the TSS/360 scheduling algorithm looked like a 
fruitful area of endeavor; however, this area was abandoned 
Mmermeause Of the time factor in building such a detailed sim- 
mwilation model and since it had taken John McCredie and 
Steven Schlesinger of Carnegie-Mellon [Ref.1] about a year 


to write such a model. They describe a modular simulation 








model designed to aid in determining tne Vv aiie 6 ieee ees 
the TSS/360 schedule table. They showed that a useful model 
can be designed to answer a limited set of -quest10ns S000 car 
complex system without detailed model Iie terme mc, suc 
components. 

Another alternative, and the one that was finally pur- 
Sued, investigated, and tested, was that of methodically 
altering the parameters of the TSS/360 Table-Driven Scheduler 
to achieve optimum system performance for the particular 
IBM 360/67 hardware configuration available. 

In order to test and evaluate the performance of TSS/360, 
which was based on five test runs with different schedule 
Cables, ME Was Lirse mecessary GO Gonsturiucl e@eseu Omar cor 
programs (a henchmark or serint) that would be re 
a realistic load on the system. his alone was a difficult 
mask Since, in a time-sharing environment, many user programs 
ma cOmpenuLrom [or Simtlar SySsvem resources and aurany 
fmerbicular time, there could be many demands or requests for 
peeearvticular resource. 

Another Ciyectm CO Obes eNds Daper sis GCONCOMpl le Loe savant = 
Sete literature regarding the performance of time-sharing 
systems that apply to TSS/360 and show by experimental tests 
mao Lnese principles and concepts improve system 


meoriormance. 








Ld... NATURE s@ie) THE s260 5B LEM 


When this institution purchased the IBM 360/67 computing 
system in 1968, TSS/360 time-sharing operating system was not 
yet available (with the bugs removed), but the future em- 
pHoyment and implementation of ToS was Phesoieelactomeanc 
sales promotion feature in purchasing the IBM 360/67 hard- 
ware configuration. As an alternate, CP/67 (version 3 from 
Cambridge Research Center) was used successfully for nearly 
two years. Then announcement was made to the user community 
that in August 1970 the IBM 360/67 would be operated as it 
was originally intended and that TSS/360 would replace the 
CP/67 time-sharing system. Prior to implementation by the 
computer facility programming staff, the TSS/360 was debug- 
meoeand vested; however, little consideration was given to 
mene Che system to the job load of the Naval Postgraduate 
Se7ool environment. 

As previously stated, the TSS/360 time-sharing system 
maomucecd [Or about six months during which time the perior-— 
mance was quite unacceptable to tChewvuser COmmbnity. “te was 
prmserved that heavy paging users could ruin the performance; 
ie. , a few users manipulating large matrices or having 
iemy Subroutines not properly linked could decrease the re- 
Sponsiveness to the other users. It was for this reason that 


this thesis project was initiated and motivated. 








The two basic approaches that have Seen used cr aii earn 
gation of existing time-sharing systemewhave UG 2c aie aye 
the analytic or simulation techniques. ) tnesanalytieyape wesc 
was the technique used to improve system performance of 
TSS/360. By methodically adjusting the parameters of the 
TSS/360 Table-Driven Scheduler using the principles of 
Balanced-Core Time and Working Set Size, improvement oe eels: 
performance of the system can be achieved. Walter J. 

Doherty [Ref.2] showed that the performance of Release 4 
Schedule Table of TSS/360 at the T.J. Watson Research Center 


was dramatically improved in a three-month period. 


Til. BRINCEPLES AND. CONCEPTS 


iMieworinctoles ana CcOMmecepus GCLSCissed sn tlie scer mem 
are a compilation of the available literature regarding the 
improvement of performance of time-sharing systems as they 


mervain to TSS/360. 


A. PERFORMANCE 

Performance, appraised by Calingaert [Ref.3] as an inde- 
Premoene CNbicy, does not exist. The concept of periormance 
can have a broad spectrum of meaning to different classes of 
people. However, fundamentally, performance of a computer 
is defined as the degree to which a computing system meets 
the expectations of the person involved with it. Some of the 


terms that are often included as aspects of performance are 


Jig 8) 








responsiveness, throughput, turn-around time, availability, 
reliability, number of terminalsesuppoOr Gedy G a ael itewe 
channel and device weil Zar on anes 41 Wemoie. 

To a user of TSS/360 sitting at 4 terminal, the sap lar, 
ef the System CO respond to Nis contends emer s predominant 
view of performance [Ref.4]. A terminal user does not care 
if only one person or a hundred people are using the system 
Simultaneously with him so long as the user thinks that 
there is a complete and dedicated computer at his disposal 
me provide certain services to him. A user would be much 
more irritated if he expected a TSS/360 edit request to 
respond in three seconds but it took five seconds than if re 
expected & response of ten minutes to some complex mathema- 
Wien! equation but at cok tChirey minuces. if other Weneelis 
the system should be much more responsive to those requests 
tO which a user expects an immediate reply, than to those 
requests during which the user knows that his attention can 
be turned elsewhere. (He could execute these programs in 
the background batch operation if the response is too slow.) 
This was a primary assumption that was made while setting out 
to improve TSS/360 performance. 

It is most important to a system manager to know the 
number of terminals that TSS/360 can support, and it is also 
important to consider the eee of work that the termi- 
meal users are doing. As Doherty points out in his paper, 
an intuitively obvious but rarely mentioned concept is that 


fOr some categories of trivial work, the number of terminals 


Je: 








receiving adequate response may incréase only after a thresh- 
old of human performance is reached. In other words, if the 
system is responding at a rate slower than a person's re- 
sponse time, any inatial improvements § ingsysvem pert emieiee 
Will firse result in the wser’s servings more work domecnena 
Only then will the system be able to handle more users at 

that levei of responsiveness. By Eten amne longer delays in ~ 
mrocessing long-running programs as the load increases, itv 

1S possible to ensure that the very short jobs will constantly 


Me preovided With @ rast response. 


B. FOLDING PROGRAMS 

Sayre [Ref.5] states: "By the unfolded form of a program 
we mean the form a program would ctvake if it had available toa 
iteea large enough uniform memory to hold both itself and its 
Sema. ...0n the roided forms the addresses have been rear— 
ranged -- folded-to-fit into the smaller address space actu- 
ally available." In TSS/360, unfolded forms of programs and 
data exist in virtual memory. When a program is executed, 
Percvions of the program and its data are brought automatically 
mace main memory for execution, which will result in automa- 
mire tOlding of the program if its complete execution space 
requirements are larger than the main memory available to 
hold it. McCredie [Ref.6] expressed in his paper that exces- 
Sive overhead and long delays while pages are transferred | 
into and out of core are two potential dangers of paging 


Meorons. iit is important to fold a program into as small a 
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space as possible to’ prevent a degenérate emt uae monme cena 
"Chrashing" from occurring diie to an Unmayuca todas 
"Thrashing," as Denning [Ref.7] states, may also occur when 

a page is pushed from core to make room for another, but then 
is demanded again and brought back anto core. WNany pwocean. 
can reach this state, and the paging rate can get so high 
that all productive work ceases. It is important to main- 
Gain a high degree of folding since it permits many programs 
mo be folded into main core Simultaneously, thereby providing 
mmepOovenvidalily signiticany increase in the Level of mulvi— 
programming. The dynamic relocation hardware available on 


the IBM 360/67 makes the automatic folding concept possible. 


C. LOCALITY OF REFERENCE 

aie proe@ranl periomianece On any paging System is direcris, 
related to its page demand characteristics. A program which 
mMemaves poorly accomplishes little computation on the CPU 
Memere making a reference to a page of its virtual memory 
that is on back-up storage, and thus it spends a good deal of 
fame in waiting for pages to be read into core memory. A 
Program which behaves well references storage in a more 
fermeprabvle fashion, utilizing the CPU longer before referenc-— 
ing a page which must be brought in from back-up storage. 
jms characteristic of storage referencing is often referred 
tO as a program's locality of reference and can be found in 
Brawn's and Gustavson's paper {Ref .8]. Therefore, a program's 


locality of reference will influence the degree of folding to 


Is 








which that program can be subjected With 2 mina mice 
on its performance. Doherty has shown (that vayprerr anew ch 
good locality will run more efficiently in a small execution 


Space than one with poor locality. 


D. WORKING SET AND WORKING SET SIZE 

P.J. Denning [Refs.9 and 10] has investigated working set 
medels with regard to program behavior in a virtual memory 
environment such as in the IBM 360 Model 67. The working 
set W(t,T) of a program is the set of pages referenced in 
the T page references immediately prior to time t. As time 
progresses, W(t,T) may or may not change; however, the 
better the program's locality of reference, the less likely 
mais that W(tt1,T) 4 W(t,T). From Denning'’s paper, it 
appears natural to try to fold a program in such a way that 
the program's working set for a given time interval fits 
petrely in core memory. Reports of Fine, Jackson, and 
MeIssac [Ref.11] provide some experimental evidence that 
the working set concept is a reasonable assumption for pro- 
gram paging behavior. Denning defines the working set size 
S(t,T) of a program, at time t, as the number of pages con- 
tained in the working set W(t,T). Therefore, it is possible 
Mmemmeave the working set size remain unchanged and have the 
Pemicing sev change. It appears natural to try to refold the 
program whenever its working set changes but, as Doherty in- 
micaves in his paper, it 1S @Gifficult to do since it is not 
known in advance just when the working set is changing. S50 


miEiest paging Systems, a working set Sige change is more 
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easily detectable; hence, it 1s possible to detec peice 
set changes at least when the working set size changes. 
Doherty describes a method for doing this, and his method is 
outlined below. The dynamic relocation hardware of the 
Model 67 system makes the application of this concept 
possible. 
Using the concepts of working set, working set size, and 
locality of reference, Doherty states: 
"During a single interaction between a user at a terminal 
and TSS/360, several programs are usually executed for 
Unatc user. Thus for the virvual execugion eine waren 
Sspens this anteracvtion, the working sev size may Or may 
not change; however, the working set will almost always 
change several times. Furthermore, for those. programs 
having good locality of reference, the working set size 
during any one time slice will usually be much smaller 
Chan the working set size for the whole interaction time 
interval. And, in addition, the maximum working set size 
for ali the time slices will] vrohably alwavs he smaller 
than the working set size for the whole interaction time 
Hevervat. KOrwthose programs having poor locality co. 
reference, the working set size for each time slice may 
frequently approach the working set size for the entire 
interaction time interval. Good locality relates more to 
the rate at which new pages enter W(t,T) than to its 
fecvual size,” 
Pee SALANCED CORE TIME 
From the previous discussion, programs having poor local- 
ity of reference and a large working set size would greatly 
meuee the level of multiprogramming if allowed to remain in 
@ere fOr very long periods of time. This result would affect 
throughput and responsiveness, since any new demands for ser- 
Vice could not be honored quickly because core would be tied 
up. The Principle of Balanced-Core Time states that the 


itemaeth of the time slice in terms of virtual CPU execution 


mime fOr any One task is inversely proportional to the 


LS 








working sev size in that interval. [neretore mea come en 
will allow good locality programs tO progress very rapidly, 
whereas it will minimize the elapsed time that any large 
program (large working set size) can tie up core memory. In | 
other words, a minimum time slice length will then be set comm 
programs with large S(t,T) and poor locality to prevent pag- 
ing overhead from dominating the system. In order to com- 
pensate for this compromise, the duration between large 


program time slices will be made much longer than the dura- 


tion between time slices for smaller working set size pro- 


RR et 


means. AS @ result; tne level of multiprogreammine age 
responsiveness will increase since more core is available 
Miewee OlLten. In addition, the degree of CPU utilization will 


increase. 


ITV. TSS/360 TABLE-DRIVEN SCHEDULER 


The table-driven scheduler [Refs.12 and 13] is an algo- 
rithm which schedules and dispatches tasks Within Chemmusbe = 
programmed, time-shared environment. NOrewspecitacal ly oeche 
Semeauler consists of a set of programs in the resident 
supervisor of TSS/360 used for scheduling, and consists of a 
Static and resident table consisting of a variable number 
(256 maximum) of 28-byte entries. The 28-byte entries are 
moaned devels of the schedule table of Schedule Table En- 
mries (STE). nae entry in any one level of the schedule 


maole Contains SWUFTicient information to completely control 
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the execution of a task. The format of the sehedule Cabile 
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Bach task which enters the system hasan e egos llemre 


describe itself to the system called they lack ago ees 





(TSI). Each TS! hase peamgern roa hey cienamiane ae 
poble. Therefore, by ehanging the valWeson Chav posimoiaes Be 


mask Will be given a complevel snew vsermon seme diame | 
Beramneters, . 


Ali TSi"*s in the sysvemeare- chained) voce rhe omeonlo son 
imemelises called the active and anacuive Visto es @ewa craic 
imeou nas two logical subdivisions called the dispatchable 
ege Cligcible lists. The dispatchable list consists of 
masks occupying core storage and waiting for the CPU, and in 
most cases, whose Scheduled Start Time (SST) is less than 


the Master Clock (MC). When the SST of a task is less than 


see 


the Master Clock, the task is said to be behind schedule. 

Mito, in the dispatchable lists are ordéred according to 

me@eir Status as "execute bound" or "I/O bound." Those with + 
heavy paging demands (I/0 bound) are dispatched first. 

The eligible list consists of tasks which are waiting for 
merry to the dispatchable. list, i.e., which are ready to exe- 
cute but have not Vere Weenie eOuenEeILO Main SeOrage. These 
tasks are ordered by priority with tne mlGWwest. Ditori ty umber 
iemiest On the list. 

Mie tReack Ives list COnctaya ot LaskS waiting on long 
delay type stimuli, such as a terminal interrupt. These 
masks, which are in AWAIT or TWAIT status, aré incapable of 
memiranuing execution until a particular interruption occurs. 


Breure 2 depicts the movement of tasks among these three i1ists. 
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Figure 2. Maintenance of TSI Lists 
tiem IO necdimle stan le NCOMnucolssuhe order in which tasks 
eee DrOURhL into the dispatchable list and the conditions 
under which the task wiil leave the dispatchable las oe 
The fields of each Schedule Table Entry (STE) can be 


id 


elassified into six logical areas. 


IY 








The first 1s a set of fields tha controler 
i.e... the tormeewsam which tasks move from the eligible to the 
@ispatchable tase (Sia E hehe STEDELTA, Sire pe ie 

The sezond is a set of fields that provide limits that 
determine when a task shall be time sliced and leave the 
dispatchable list (STETSVAL, STEQUANT, STEMAXCR, STEAWTEX, 
SIEPRMT) . 

Third is a set of fields that specify the level transi- 
fron that will be made when the respective limit or stimulus 
Mas been reached (STEPULSE, SULIUL ST ID SRD Weleda eee UN IIe 
SHOAWATT, ATEHLCK, STELCHL, STEWLCK, STECWO, STELCF, STEPRJ3, 
SENSE) . 

Next 1s One itel da Wwhtea scan su nu Tabe Wa Cian eer ine 
order of tasks on the dispatchable list (STEMRQ). 

| mitfth 2S a set of fields which allow the resident 
Supervisor to release some of a task's pages rather than 
time slice the task (STEST, STESRI). 

Pinally, there is a field which can override the system 
@ewenlated drum share of private pages for a task (STEDSH). 

Append:x A contains a description on Each or the. frends 


Or parameters within a schedule table entry. 


fee SLERUCTURING OF SCHEDULE TABLE ENTRIES 

By implementing the scheduling principles and concepts 
WeevlOusiy discussed, a wide spectrum of scheduling strate- 
gies can be implemented by altering only the entries within 


the schedule table. 
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In constructing the schedulle Cables  accordimee ves vic 
table scheduling strategies, different sets of levels are 
grouped according to some primary goals of scheduling. 
Several particular programs (tasks) are treated differently 
than other programs, e.g., system operator task, bulk I/0 
task, logon, and logoff. Figure 3 shows an example of a 
schedule table. All other programs are divided into the 
interactive and batch categories. In general, the same sets 
oi levels exist for both kinds of programs, cane that inter- 
active programs have priority over batch programs; that is, 
Bitberactlive programs, initially, have a greater urgency to 
eeary, than do the batch, Ihe number of batch programs al- 
mewea tO run simultaneously is arbitrarily restricted so 
that adequate space will be available for anticipated inter- 
active programs. The interactive sets of table levels are 
Pmeuped according to the following: 

i Lnemevary Hoe toe 

The starting set of table levels are used to handle 
Memeinputs from the terminal. The functions of this set of 
Basle levels are to facilitate a rapid reply to the terminal, 
if possible, and to make an sindiet all Wud Siem Or Tae presente 
ferns Sey size Of lon@eér running programs, so that the best 
emerance to the looping set of table levels can be chosen for 
moe Darticular program. 

To accomplish this, several successive table levels 
with high priority, small execution time limits (100 milli- 


seconds), and increasingly larger core space limits (16, 32, 


Zl 








STARTIRG 


SET 


HOLOING 
INTERLOCKS 


SET 


PUBINOICE 


WAITING 
POR 
INT SRLOCK 


SET 


SQL ING 


TNTTPACTIVE 


Su 


LUD°T NG 


BAT TH 


Ser 


AdAIT 


INTERACTIVE 


FET 


LO PL NG 


Is TESaACTIVE 


SET 


LODPI NG 
wT 
sor 


“TAPTING 


SS 


SYSOP ERO 
IATERACTIVE 
ISTEBACTIVE 
INTERACTIVY 
ISTEFRACTIP F. 
INTPRACTIVE 
IBS TFRACTIVCE 
IBTERACTIVE 
IATRRACTIVE 
IAPTPRACT IVP. 
BULK I-0 
BATCH 

BaTCA 

BATCR 

BATCH 

RATCR 

BATCA 

BATCH 

BATCH 

BATCH 

LOGON 
tocore? 


SYSOPZRO 
IATERACTIVE 
TNTPRACTIVE 
TSTPRACTIVE 
RJLK £-0 
BATCH 

Bane 

LOGON 
LUGOPP 


an Ite 


LOGOPP 
LOGOR 

BOE Kee 0 
SYSOPERD 
INTERACTIVE 
TX TPRACTEG® 
IATERACT IV P 
RATCH 

BATCH 


SROWING 
DFLAYTING 
GEOWING 
GHOGING 
GRAZING 
SSOd1NG 
NELAYIANG 
NELAYIN: 
DELAYING 
OELAYING 


QIWING 
NELAY ING 
GHOWTNG 
GRDAING 
GROOT N. 
GROWING 
DPLATING 
OPLATIRG 
DELAYING 
DELAYING 


“ROWING 
NELAYIAG 
TROWING 
GRIWING 
GROWING 
GROWING 
DZLAYING 
MELAYEXS 
DELAYIRG 
DELAYERG 


SHRINKING 
OPLAY VAG 
SHATNER TKS 
SHRUNK ING 
SHRIHKING 


SHVINKA ING 
OPRLAY ERG 

SURINK ING 
SHRINKING 
SHILNEKDNG 


ENTEPACTIZE 
UN TSHAG TU Ve 
INTERACTIVE 


ee | 
C246 
ya 24 
du 2h 
wor 


39246 
OO 2h 
0026 
OU db 
0073 
on13 
00 2h 
QU2h 
oOo1s 
0013 


00 2h 
NO2n 
9013 
0010 
9054 
J0U8 
09013 
0010 
NOo8 
0004N 


0026 
00 2b 
0024 
0024 
AN 2h 


OU2t 
OC2h 
4926 
TV 
0024 


goo 
099046 
JOO 


Prcure oe 


1 


11) 


01 


20 
$n 
uO 


ano 


0000 
0000 
DODO 
0000 
0obOD 
00D0 
0090 
DDVO 
ob0y 
0000 
0090 
012°F 
012P 
O12Ff 
012? 
DI2FP 
012? 
012P 
012P 
O12P 
00:10 
0000 


OF 
O12P 
OV2P 
Awe 
912P 
O12F 
O12P 
V2 be 
OVLP 


0300 


90)93 
0000 
00090 
0399 
0010 
09009 
aQn0o 
gU2P 
O10F 


000n 
0030 
GUID 
00u0D 
0009 
O0J) 
on000 
gon23 
0000 
Jun? 


J12P 
OJP 
012¥ 
ai2P 
O12P 
017F? 
HUsP 
[on ral 
OVE 
012P 


012°F 
ver 
O12F 
OV2P 
O12P 
OV2P 
012? 
J12? 
012P 
O12P 


0000 
0000 
0009 
0090 
0099 


012F 
Wie P 
UIP 
Be [ 
Oe 


0000 
909% 
9009 


nu o@DwDyO Ss 


Schedule Table 


ed 


tf 

x 
ove 
zOrst 
ernanr 


Example 


FA Pr « 


23 
24 
24 
24u 
24 
24 
24 
24 
24 
24 
Par 4 
Al 
2} 
2} 
Zi 
Het 
2? 
Zi 
2] 
793i) 
21 
20 


23 
24u 
2% 
Zh 
Par 4 
2i 
2 
21 
20 


24 


20 
21 
22 
23 
Zu 
2) 
26 
if 
24 


Zu 
25 
Lay 
éb 
2b 
Zh 
Zo 
2b 
Zb 
2b 


2? 
2} 
73 {4 
24 
2u 
au 
2u 
Pas 
24 
2 


24 
24 
2> 
26 
26 
26 
25 
26 
26 
26 


24 
25 
2b 
2% 
25 


27 
Zot 
2u 
2? 
2? 


7 ae) 
26 
26 


ww & DO 


DU 
1P 
VP 
1P 
VP 
1P 
VP 
iP 
VP 
1? 
UA 
UB 
uc 
vo 
Uz 
OP 
tne) 
VW 
V2 
Le 
18 
US 


00 
aR 
VP 
1P 
vA 
1A 
IC 
14 
es 


VP 


14 
14 
OA 
OU 
VP 
P 
1P 
Of 
13 


VP 
1? 
1P 
iP 
1? 
1? 
Uk 
VP 
Whe 
VP 


ja 
su 
39 
$A 
$B 
$C 
4 
J’ 
10 
sc 


1P 
VP 
1P 
le 
1P 
VP 
VP 
VP 
VP 
1P 


VP 
VP 
IP 
VP 
VP 


40 
uO 
uF 
uP 
ba) 


1P 
VP 
Ve 


ww & Bg 








48 pages) are established. As each program request enters 

from the Terninale see move upward through these levels 
each time it exceeds its core space Timit. theme wee 
program exceeds its Cime limit av any of these Neveleryrner ore 
space limit of that level is used as the estimate of the pro- 
gram's present working set size. The program is then consi- 
dered to be a longer running program and its future execution 
will be controlled by the looping set of table levels. When- 
ever a program exceeds its largest space limit, the largest [ f 


allowable working set size (64 pages) will be used as_the f 
———— agape f 


- | yp 





first estimate or Dulurne excicuLionunder Comiene), Of sehe 
looping set. | 

When a program completes its execution, it is returned 
Memene initial Starting set table level to await the next 
mrout irom the terminal. 

eee Je wlooene Set 

The looping set of table levels performs the follow- 
moe iunctions: they use the fields of the schedule table to 
iemerOow a2 program's working set size by regularly overestimat-— 
ienand underestimating its time and core space requirements 
i 2 minimal Pome bie cOmdanece Withee ene sorinc tele “OF 
balanced-core time; they cause the load that is generated by 
ieme running programs to be spread out in time to allow start-— 
ing set entries to be processed rapidly; furthermore, they 
Optimize the CPU utilization, and thereby penalize programs 
With poor paging characteristics by causing programs with 


minimal paging requirements to be selected to run mucn more 


2a. 








frequently than those with large paging requirements. This 
penalty occurs only when the program has poor locality of 
reference and a large working set size. 
3. The AWAIT Set 
The AWAIT set is a special set of table levels re- ., 
served for tasks doing tape I/O and other kinds of AWAIT 
operations. AS previously described, in each table level 
there is an AWAIT extension field, which is an elapsed time 
maverval during which a program's current oman set pages 
are kept in core while the program remains idle in the AWAIT 
state. This can cause severe elongations of real. time com- 
memeead LO Virtual time; so that tasks with Smaller values of 
virtual time are placed in this set of table levels rather 
than tasks of the same working set size which are in the 
Heoping Set. 
4. The Holding Interlock Set 
The holding interlock set is also a special set that 
ifeereoserved for programs that are currently holding inter- 
locks on some system resource. (Holding an interlock means | / 


; : j 
Pe@eeesOme program is using a resource and preventing other; 


programs from using that resource.) Programs in this set 





eeeeweiven high priority so that the interlocked resource [| 
may be quickly released. An insignificant change in the 
Werking set size of programs operating in this set is 


assumed. 
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5s The: Wasivaine = lem Tape miee aa ee 
The waiting-for-interlock set is another special set 
of levels for programs that are waiting for anvertoc.e ve soe 
released’ that are currently beimeriecld b) ot Meme wer oi. 
ma the holding interlock set. Untill the anvericc 2a. eee 
leased, programs in thas sev of wabille levels yal nepal. 


be considerec for dispatching. An instpnificant change in 


mile working set size is @als0 assumed for the interlock set. 


V. EXPERIMENTAL PROCEDURE AND RESULTS 


im order TO make a number Of CtCest runs wsing diiferens 
Bemecaule Cables, it was first necessary to provide a number 
Of programs that would characterize a "realistic" load on 
Piemoysctem relative to user demands at this school. This 
was necessary since TSS/360 was no longer the current time- 

poe eee 
wiemiIne system in use at this computer installation, and a 


fixed load was needed to make valid performance comparisons. 


A. DEVELOFMENT OF A BENCHMARK 

meewWas previously discussed, the benchmark design concept 
for general purpose time-sharing systems is not an easy task 
wemmmaerlLake and is confounded by two factors. The first is 
the variety of demands placed upon the system and second is 
Miemeovochastic behavior of a time-shared system. Arnold D. 
Karush [Ref.14] presented an excellent discussion of the de- 
velopment of a benchmark design for the ADEPT Time-Sharing 


Pyovem at System Development Corporation, and pointed our 


ap 








specific functional variables (compute activity, interactive 
activity, I/O activity, page activity, response ral loereton, 
user population, and swap activity, that affect system 
performance - specifically respomse time and throug. 
marush discusses two General progranmeecsien tect avec sce 
Be measuresthe performance of vaime-sharing Systems y— sume 
analytical and stimulus methods. The analytical technique 
mavolves the insertion of probes into the system running 
Mereer actual Operating conditions. The stimulus vechnigue 
eetesists of a "black box” SOncent and involves applying a 
metro l led and measurable set of stimuli to the black pox 
Mmemactvivate oie mee oneal Vetebaples and thenmousettyc seme 
effect of the stimuli upon the system. 

ine stimuius technique was used to develop the scripts 
for the experimental tests used in this paper; specifically 
a similar set of programs was used by the CP/67 and TSS/360 
Time-Sharing System comparison grouvo [Ref.15]. 

The final set of benchmark programs used in the test 
mie were as follows: 

PLILG 2 ena Bay lS conp Lavan 

PLISM - small-sized PL/I compilation 

FORT ~- Fortran program that is compiled 

Boreas’ — Fortran program that 1s executed 


BOIT — execute routine that edits a simple program and 
ieee smeme Cire ad 7 Op team 


EAGHE — Fortran program which executes a large matrix 
mu Leite iareation. 
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B. MEASUREMENT TECHNIQUES 

Two types of performance criteria were Used ToOmmeasuice 
and judge the improvements in performance. The measurement 
consisted of observing the response Ctames and Chreoughiamne 
ihe benchmark programs used in the tests were writtemerem: ve 
the real time at the commencement and at the completion of 
a compilation. The throughput was calculated by observing 
moe completed compilation or execution of a particular tyse 
woo. The figure obtained by this procedure is called the 


mireourchput factor and was obtained as follows: 


IP SSG 8 oc NT, ) 
where SS = Sample Size (number of completed jobs) 
RD = hum) Dua av aon 
NT. = Number of terminals running program type i 


imecssence, the throughput factor is the reciprocal of the 
me LO execute the program, modified by the size of the 


Sample. 


C. TOOLS FOR MEASURING PERFORMANCE 

Unfortunately no hardware or software measurement device 
Meaewavallable to measure resource utilization and performance 
of TSS/360 in this research. A software measurement tool 
called SIPE was obtained from IBM, but the required data 
eeelysisS programs could not be obtained. Thus the actual 
measurements could be made, but there was no means of convert- 


ing them into meaningful information on resource utilization. 


2 || 








The problem of developing a data analysis program to analyze 
the data from SIPE was considered as beyond the scope of this 


research. 


me PRESENTATION AND DISCUSSION OP Sais tears 

Five test runs were conducted using different schedule 
Cables. The results of these tests will be presented and 
eascussed in this section. 

The IBM 360 Model 67 configuration of the Naval Post- 
Sraduate School is shown in Figure 4 and is very similar, but 
feu identical, to the IBM T.J. Watson Research Center's Model 
ey coniiguration which Doherty usec for his work. It should 
be noted that when the TSS/360 Time-Sharing System was 
implemented at this school for the months previously méen- 
tioned, the new IBM Watson Research Table by Doherty was not 
used. The initial schedule table used in TSS/360 is shown in 
Appendix B (Figure Bl). This cable providedspocr perren- 
mance to the user community. Just prior to TSS/360 being 
replaced by the new CP/67 version time-sharing system, the 
new IBM Research Schedule Table arrived and was implemented 
by extending and using TMPOrLanuwparameters thavowere never 
used in the old eagetex A significant improvement in perfor- 
mance was observed. This improved schedule table is shown 
imomemooendix B (Figure B2 ). In fact about a fifty percent 
increase in utilization was observed, and yet, it was clear 
that more improvement could be obtained. It was not until 
these tests were begun that the new IBM Research Table 


(Figure B2 of Appendix B) was implemented and tested: 
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Lee Shes 

Test 1 was a preliminary test in which the benchmark 
programs (or scripts) were initially used and in which the 
new IBM Watson Research Schedule Table (Figure B2 of Appen- 
dix B) was used. The load configuration and performance 
Stavistics for this test Cam be Seem an Neeure pean Rte 
Operating with a good sampling of all the script except 
paging, produced a mean response of 8 min 37 sec for a large 
mieyt compilation, 4 min 30 sec for a small PL/1 compilation, 
1 min 8 sec for a Fortran compilation and 48 sec for an 
pom. This test did Not provide a heavy load to the system: 
Was table, however, did provide better responses than were 
previously observed by the user community when TSS/360 was 
femme Of a reguiar basis using une Gid scneduie Labie. 

ees 2 

Test 2 was conducted, with the same schedule table 
Mmeea ifn Test 1, to provide a more realistic mix with different 
ratios of edit-to-run (compile and execute) programs and 
meter load on the system. An important factor to remember 
in scheduling is that almost any scheduling technique will 
show similar Meas) eerie, Miele ig eevee) Bib ie eis eMonaull yo iilqketol 
moe Cemandgd for system resources gets large that scheduling 
G@aiferences are clearly indicated. The run durations were 
also lengthened to provide a steadier load on the system. 
The load characteristics and the performance statistics for 
test 2 are shown in Figure 6. Under this change in load, 


the response times have correspondingly increased significantly. 
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Figure 6. TSS/360 Test 2 
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Each test run was conducted under a4 terminals igccdeen: 
of users. Runs three and Rone were conducted with heavy 
paging, and as a result, a greater delay was observed in the 
response to a request. It was believed initially from the 
first two runs that the PL/I compiler characteristics produced 
the heavy load and the poor response, but when several heavy 
meeings programs were added to the load, the performance was 
degraded even more. Paging in TSS/360 is handled by disk as 
melt as drum; and since disk paging is slow, this mien se 
wae Ol The major problems. 

Sy Mesias 3 

When test 3 was performed, one of the three core 
boxes failed. The results of this test indicate that TSS/360 
erat ino wlth Ondy we Core bDOXxXeSeralhner Tham tierce wilt 
Eeoduce a much lower system perirormance, so low that the re= 
mets sare meaningless fOr a comparison and are not ineluded 
Maechis thesis. 

4, Test 4 

Without changing the schedule table of test 2, runs 
ene through four were conducted to see if a different load 
peuld change the performance characteristics. Run frour 
eeemead tO be a good sampling of the scripts and provided a 
mavy pagping Joad, and the performance characteristics were 
mouL Fhe Same as that in run three of test 2. The load 
Semaitions and periormance statistics for run four are 


shown in Figure 7. 
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Figure 7. TSS/360 Test 4 
Boeaa Conditions and Performance Statistics 
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Run five was conducted with the IBM Research 
Schedule Table patch altered. This modified IBM schedule 
table is shown in Appendix B (Figure B3). The table para- 
meters that were altered for thas srun sare Tounceaie tie 
table levels of the Looping Interadetvive Sets and Tie sora cr 
ine Set of the schedule table, sincesenese Secs ome. 
areas in which the most improvements in performance could 
be realized. Several fields of the schedule table levels 
were altered, but none were changed drastically. This was 
Gone so that any degradation to the system which may have 
waclrred [retimemancing pearamever values could) be Coseryed: 
iWine fields altered and the reasons for the alterations were 
as follows: 

The delta-to-run parameters were increased so that 
mae larger working set size programs could get into core 
faster but less frequently and remain there longer with 
larger values of time-slice end. The smaller size programs 
mel l Set priority through the system. 

The AWAIT extension field increases the time 
allowed for the larger size programs to remain on the dis- 
patchable list before being forced to time slice. Since a 
mesk in AWAIT status is normally moved from the list of dis- 
patchable tasks, and since this can cause a delay in redis- 
patching the task, the idea was to make the AWAIT extension 
large enough to allow for completion of I/O operations. 

A tew Priority values were changed , nee nlaveyene: 


priorities determine the position a task will assume within 


oP 








the list of eligible tasks: Uthat a6) low Driorit, Sauipe. 
are given precedence over higher priority numbers. 

The Quantum Count and Quantum length fields were 
altered. These parameters deci seuntine the time slice, which 
1s dynamicsm@eor tasks assiened £oO vias Cnty = iio deee 
Guration equals Quanta Count times Quapeume Tengu ome 
milliseconds. These fields were altered to see the effect 
of the Balanced-Core Time Eenemeee = where the time slice 
emeatiom in terms of CPU execution time fom a task as in 
memsely proportional to the working set sige in that tame 
mecerval. Dhas will Bee ee elapsed time that any large 
job can clog memory and allows jobs with good locality to 
Breorress rapidly. 

The maximum core page residency values (MAXCR) have 
been selected to minimize task performance. Trivial and 
many non-trivial commands require less than 35(23 hexa- 
decimal) pages allowed in the small conversational levels. 
However, some non-trivial commands take more pages, causing 
Mmeemvask tO move Go other levels. if taskss.with the Steal 
Request Flag (SRF) on move into core faster than pages can 
be released, eet Ta exceed the MAXCR limit and be time 
sliced. 

The maximum relocations per quantum field was 
altered. The smaller the value, the greater the guarantee 
the task will be considered I/O bound and its order in the 
Gispatchable list will not Chanee., Theretore, tasks which 


muse be serviced Gan remain on or near the top.,of the 
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Gispatchable list by assuming them to levels with small MRQ 
Values 

The recompute flag fied was alvered tt Ween 
these Jevels fall behind senedules they wads be eae meee 
Pervence through The computation of Sumer T schedule start 
time. If the preempt flag is on, a task can be time slice 
ended if @ higher priority task is ready and can not be 
dispatched. 

ine Voce tlires Odd Pelt. sere eguiceas lam ve iluer 
Since it was felt that a 100% page stealing value was not 
mecessary. The scan threshold is related to eck stealing. 
ies should ne NOvednUdaG elie ws Fealine sme ch amnses anteny sets 
the steal flag was not implemented in the old schedule table 


thet was used initially with the s 


a 


7efem. ees ee es at VW aly 


— @ @ ok Oe 


Mes altered to allow page stealing. 

As shown in Figure 7, by primarily increasing the 
delta-to-run and quantum fields, the large working size 
programs (PLILG) were penalized in their response times, 
mmereas an improvement in response was observed in small 
met and Fortran joueiatons MOvWie Vier ide we Ei eo 
Prams, response times were even worse during this run than 
Merore and the throughput factor went down. 

Soe Leste. 5 

idemnas Ue mrEViog sComame ved Using three dri fereny 
eemecdulle tables. The characteristics for thi#s test are 
shown in Figure 8. Unfortunately, there were only 20 ter- 


(ieomloagine thie svoucem. since the Other terminals were 


Se 








inaccessible or inoperable. The timewwacealso. iii cee 
these test runs so that the durations were shorter than was 
@esirable.. The schedule table for run Poirce is (one iimeaa 
Figure B4 of Appendix B. The parameters that were altered for 
mane Schedule table for run three were une delta—-vo—mumet aces 
which were set to very large values, and the quantum PiesLéle | 
Although the load was not as heavy as that of test 4, these 
test runs do show significant improvement, and the increased 
performance is the result of judiciously altering these para- 
Meacome, Ine response times for PLILG programs for runs owe 
macmuikee were abouvw the Same, while the seepanse Gime for 
fen Oroprams was better for run one than for two and three: 
ieierer, if IS expected thal if-a heavicr Toeesegedt esr 
meeeceo On the system, run three would have provided the bev— 
ter performance statistics. The response times for small 
size PL/I programs, and EDIT programs for run three show bes- 
hem response statistics, and the response time for FORT 
programs for run three shows an increase over run two. 

Figures 9,10 and 11 show the difference in response times 

meme ach of these runs. The throughput Rea CrOmmcOuUrlG: N@cmewc 
obtained for bigeantd small Pil7 il .erograms, but run three 

preews an ancrease in throughput over run two for FORT pro- 
Prams but about the same as run one. For EDIT programs, run 
merece Shows an increase in throughput over run one and two. 


Pigures 12 and 13 show the difference in throughput. 
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Figure 8. TSS/360 Test 5 
COR mCOmeLeLomomainad Prerrormnmeance Statistics 


8 








S} f RUN 2 


ae 
2 = 
MEAN 
‘ 


RESPONSE 
TIME O————)—__. 


(min) 





NUMBERS OF TASKS 


Pigure Y¥. Kesponse Time VUomparisons for Fortran Compilations 


or est 5 
ei 
ee 
© 
30 RUN 1 
ME AN a0 
RESPONSE _—_ 
TIME | : & BUN oe 
(min) 10 


NUMBER OF TASKS 


Figure 10. Response Time Comparisons for Small PL/I 
Compilations of Test 5 


40 








2 





MEAN 
RESPONSE 10 
TIME 
(min) o——b—— 4 RUN 2 
8 
© @——-e—— 9 RUN 1 
‘% (5 nner SE] nme [me [i RUN 3 





NUMBER OF TASKS 


Fieure 11. Response Time Comparisons for EDIT Script of 
Vest eo EDIT Commands 3 


moe © aun 1 

.90 ra 

80 3) 
THROUGHPUT 
FACTOR » {0 

60 © 

BB Q RUN 3 

56 - 

40 ie 

30 o——B——p—- 8 ——& Bin 5 





a a S Uy D 


NUMBER OF TASKS 


meenre 12> Throughput Comparisons tor Fortran Compilations 
Ot Lestanos 


Hy 








ao 


ie 
ENS 
Gg 
feaROUGHPUT pu 
FACTOR 
.20 Gi G—-a 


}.! 





di 2 3 y 


NUMBER OF TASKS 


Meeure 13. Throughput Comparisons for EDIT Script ( 6 EDIT 
Commands ) of Test 5 


42 








VI. CONCLUSIONS AND RECOMMENDATIONS 


The objectives Of this paper were Co cream Z alt e727 
able literature regarding improvement of performance measures 
and techniques for the TSS/360 Time-Sharing System Schedule 
Maples and to show that these principles and concepts could 
be substantiated by performing experimental tests on the 
Computer. As a result of altering the parameters of the 
TSS/360 schedule table, improved performance over the initial 
system perfcrmance, when the TSS/360 system was in full ope- 
Warmer, was ObServed. FKFrom these tests it is evident that 
because of differences in the user community and in hardware 
meme uracions it is necessary that certain Parameters in the 
table-driven scheduler be set for each installation to improve 
Gmeeeoyscvem performance and thus maintain a satisfied user 
community. 

It has been shown by these tests that the Naval Postgra- 
duate School's Model 67 computer could support about 20-25 
Seenulcaneous users using a modified iBMynesearmch scmeduile 
Moore, whale maintaining a fair response to the trivial re- 
Sete os, and simultaneously servicing large users rather well. 
With more work on the schedule tables, better service could 
be provided for a greater simultaneous load. Once the TSS/360 
Time-Sharing System was removed as the installation's time- 
Siaring; system, the time available for testing in this project 


was restricted. Many more valuable tests remain to be 
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performed to eventually optimize the performance of the sys- 
tem through the judicious alteration of the parameters of the 
TSS/360 table-driven scheduler. 

There were many fields of the TSS/360 schedule table that 
mere not varied and tested] or eGxample. Vauiiie taew lec eevece 
a table was designed to test the page drum mechanism, but 
Since this mechanism was not yet implemented into the soft- 
ware, this table could not be employed. The present values 
eee the schedule table at this installation show a 0000 default 
to the system calculated. minimum number of pages on disk for 
meelesusers. This value could be increased to allow some 
@Gasks to be allocated greater space on drum in order that 
mewer Of their pages have to be moved from drum to disk. 
Nielson [Ref.16] in his simulation studies of time-sharing 
Syocems, showed that disk paging can be very slow and can 
reduce system performance substantially, and proposes that a 
drum be used in place of the disk. Since this installation 
Meee DOCH drum and disk paging, an alternative solution could 
Wemeeo DUrchase another drum for paging. Also, revision of 
the disk management .algorithm could be made. 

AS mentioned at the outset of this paper, a more flexible 
eooeach CO evaluating the effects of changing different 
peeeteoule table parameters on the performance cf the system 
would have been the simulation approach rather than an analy- 
Mmeal approach. However, such a simulation model would have 


to be limited in terms of expensiveness of design and running 
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time. Also, there is always the very difficult problem of 
validating the simulation model 

From the tests conducted in thismpanecr ate opr ane are 
optimally tune the scheduler by trying various schedule tables 
in the proper type of environment is not an easy process. 
mnaere were many factors which limited more speedy progress 17 
Cuning the scheduler to the job load of this school's environ- 
ment. The benchmark that was implemented for the tests may 
not have accurately represented the user community, although 
a great effort in this direction was made. Since loads are 
eonstantly changing, it is important to develop a methodology 
for automatically producing scripts that are characteristic 
at Chis installation and then to verify that they are accurate. 

the use of the TSS/360 software measurement technique, 
SIPE [Ref.17], would have been very valuable and helpful in 
Pewoolishing a good benchmark for developing, evaluating, and 
improving the interactive system. SIPE and its data-reduc- 
tion program could also have been very helpful in evaluating 
changes to the schedule tables and the effects on system 
performance. These measurement tools could also provide 
valuable statistics about each task as it is being processed 
by the system. Software counters, as Doherty used, could 
also provide information about each task as it migrates 
through various levels of the schedule table to more accu- 
rately verify the principles of working set size and balanced 
core time. De Meis and Weizer [Ref.18] established by exper- 


mienval means in developing RCA's Time Sharing Operating 
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System (TSOS) that by using certain measurement devices, the 
working set size and balanced—core time of programs Cane be 
oueerera ange ver? hacen 

Although SIPE produces some degradation LO .Lhews, sven. 
this is not considered serious. The only way to moniuor 2a 
System without altering its operation is by external hard- 
ware monitors. Schulman [Ref.19], for example, discusses a 
hardware monitor (SPAR) that also is used to measure TSS/360 
end that does not degrade that system. Another tool that 
has been extremely useful in TSS/360 evaluation and improve- 
ment of performance is the instruction-time trace monitor 
(27M) [Ref.20] which is a combination of software and hard- 
ware. With the aid of these additional measuring devices, 
ies believed that many more admprovements could be made to 
the performance of TSS/360 by further adjustment of the 


entries in the schedule table. 
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APPENDIX A 


SCHEDULE TABLE PARAMETER DEFINITIONS 


ie VEBie Co CELE Vey te 2 
Relative entry number in schedule table. The level num- 


ber is used to relative address within the schedule table. 


eee RITY (STEPRIOR), 1 BYTE 

me OTLOriGy Of a level wan econuneli on with. Che sehedule 
Start Time (SST) is used to govern the allocation of CPU re- 
sources to a task. Only those tasks brought into .the dis- 
Metemable list Can increase in core usage. Zero is the 
highest priority. When seeking to bring a task into the dis-- 
Meeenable 11St, the highest priority task behind schedule is 
@mesen. If no tasks are behind schedule, the highest priority 


Task is chosen. 


QUANTUM LENGTH (STETSVAL), 2 BYTES 

The quantum length is the number of time units (one 
quantum) a task will be dispatched or the amount of time to 
Pemuioed AS a factor in determining how long a task will be 
pemowead tO run before time-slice end. One unit represents 
Seo Milliseconds. A quantum represents the maximum virtual 
femery time that a task will be dispatched. The system will 
then make a decision as to whether the task may have more CPU 
time based on the number of quanta used (see STEQUANT) or 


interrupted by a time-slice end. 








MAXIMUM NUMBER OF QUANTA (STEQUANT), 1 BYTE 
This field represents the maximum number of quanta (STES- 
VAL) a task may use or receive when it is in execution before 


a time-slice must occur. 


MAXIMUM PAGES (STEMAXCR), 1 BYTE 
Rais 11eld represents Che macamumn number. ot privage 
mavsical pages allowed in core before a time-slice end or pace 


mieeal will occur. (see SCAN THRESHOLD) 


MAXIMUM DISK I/O OR PAGE READS (STEMAXRD), 2 BYTES 
This field represents the maximum disk reads or writes, 
or maximum number of page relocations a task will be allowed 


before a time-slice end will occur. 


pee THRESHOLD (STEST), 1 BYTE 

If the steal request flag (STESRF) is on, the resident 
emmeervisor will release some of a@ task's pages when the page 
count equals STEMAXCR (maximum core page residency values). 
M@meescan threshold is the percentage of STEMAXCR pages to be 
retained. The scan threshold is a percentage specified in 
hexidecimal Gree: S07 cor bac © = 508 Dace oO) hem suc. 
mee, Occurs, the task is not Time-sliced, but stays in the 
Gispatchable list. However, the schedule table entry in the 
TSL is changed to the value specified in STENSL (next steal 


level). 
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PULSE LEVELS ( Sie Pigs yee ieee sane 
This field represents the schedule alse Fev] eenii aaee 
be used if the pulse Service 1s requested Dy Cie users baie 


pulse service elieows Che User Co request aas level ehameer 


AWAIT EXTENSION (STEAWTEC), 2 BYTES 

Tas flelad represents Ehe messemum Gime that a Paice 
jae an AWAIT service, is allowed to rémain in the dispatch— 
able list while waiting for an I/O operation to be completed. 
Hie units are 3.33 milliseconds. If the 1/0 operation has 
not completed before the time limit specified, the task is 


Time-sliced. 


DELTA-TO-RUN TIME (STEDELTA), 1 BYTS 

opeciries the real time interval at which a task is to 
be given a Sicewog eCPl time a Miao itleid SPCC eCS wa fact om 
which is used to calculate a new Scnedule Start Time (SST) 
FOr a task as it moves from one state to another; i.e., as 
the task becomes ready, in AWAIT or in TWAIT. The value in 
Mas field is multiplied by 852.5 milliseconds and may be 
Combined with the master clock time or the old Scheduled 
sweey Time 1f the old ss! is negative to determine the task's 
Mew ool. If delta—-to-run equals Zero, the SST is set to 
Mero and the task is automatically placed behind schedule. 


(see RECOMPUTE FLAG) 
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(TSE) TIME=-SLICE ENDS CSR Eee D) =a les B Yaa 

This field mepresentarvme Schedule abie we ie a ae 
be used when a time-slice end occurs because of the maximum 
number of quanta (STEQUANT) or a maximum disk I/O (STEMAXRD) 


has been reached. 


HeetMUM PAGES TSE (STEMPRE)) 1° S805 
This field represents the schedule table level entry to 
be used when a tmme-slice end occurs because of the maximum 


pages in ccre (STEMAXCR) has been reached. 


mieT TSE (STETWAIT), 1 BYTE 
This field represents the schedule table level to be 
used after a time-slice end occurs because the TWAIT service 


has been used. 


moo TSE (STEAWAIT), 1 BYTE 
iors itches reuresents cenewsecnedule Val lewWevel Ventry mre 
be used after a time-slice end occurs because the AWAIT service 


has been used. 


MecOMPUTE FLAG (STERCMP), 1 BIT 

fievunewrecomsuyve flap is on, the task's Scheduled Starr 
Time is computed to place the task back on schedule as des- 
cribed above under delta-to-run (STEDELTA). If the flag 
is off, past performance (if behind schedule) is taken into 
eeeounty by calculating SST as the present time plus delta- 
e-run minus the amount behind schedule on the previous 


time-slice. NOTE: When a task enters the eligible list 
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directly from the dispatchable list, thewsencd ules startecun. 


is calculated as 1% the recompute sl lac sncwo nme 


PRE-BMPT PLAG 4 STEP RMP) ee 
A task on the dispatchable list whose pre-empt flag is on 
may be forced to time-slice end so as to make room for a task 


from the eligible list having a higher priority. 


wes REQUEST FLAG (STESRI), 1 BLT 

Meveask On Die RG Spaibelab te Antsy BWiiOce soiree AEE HEE tae 
is on will have pages released (stolen) when its private 
Peees in core-reach the STEMAXCR limit. If pages are brouwghs 
in faster than they can be released so that the STEMAXCR 


irr 15 exceeded, the task will be time-sliced. 


MepeiMuUM PAGE RELOCATIONS PER QUANTUM (STEMRQ@), 1 BYTE 
peccilies the maximum number of page relocation inmver— 
Pietions allowed per quanta before the task is declared pag-= 
ie bound; i.é€., a task is considered to be execute bound if 
imesmaumber of page relocations per gucaauaterene is less than or 
eae TO STEMRQ. Boobie wound tasks are placed at the end 
Smee Gispatchable list to allow non execute bound tasks to 


Ser lap their paging 1/0 with execute bound tasks. 


MemDING INTHRLOCK CHANGE LEVEL (STEHLCK), 1 BYTE 

This iield represents the schedule table level entry To 
be used when a time-slice end occurs (except for AWAIT or 
TWAIT) and the task is holding a Virtual Access Method (VAM) 


interlock. 


Syl : 








LOW-CORE HOLDING INTERLOCK (STELCHL), 1 BYTE 
This field represents the schea@yule Tal lew ite (eis a ane 
be used when a time-slice end occurs because of OW = Comme and 


the task is holding a Virtual Access Method (VAM) interlock, 


WAITING ON INTERLOCK CHANGE LEVEL (STEWLCK), 1 BYTE 
This field represents the schedule table level entry to 
be used when a time-slice end occurs and the task is waiting 


on an interlock, 


CONVERSATIONAL WRITE ONLY (STECWO), 1 BYTE 
tis field represents the schedule table entry towne vee 
when a write without response messaze is sent to the terminal. 


The level change occurs without a time-slice end. 


rewecORE BORCED TIME-SLICE END (STELCF), 1 BYTE 
This field represents the schedule table entry to be 
used when a task is forced to time-slice end for low-core 


maeeto 15 Noy holdange an interlock. 


PREJUDICE CATEGORY 3 (STEPRJ3), 1 BYTE 


This field is not used in the system. 


ieee STRAL LEVEL (STENSL), 1 BYTE 
This field represents the schedule table entry to be used 


fem stealing occurs. The task is not time-sliced. 


Wael SHARE (STEDSH), 2 BYTES 
This is the number of drum pages reserved for a task. 


Mhere are about 500 pages available after startup on a one 


De 





drum system and 1400 pages on a two drum system. In eave Ocul. 
the number of a task's private pages on drum is 9] functions o 
Che number of tasks logged on, the number of drums, and the 
time since the last time-slice. If the number of unassigned 
drum pages falls below a pre-determined limit) some pages 

are moved from drum to disk. Each task receives a system 
calculated minimum drum space. The drum share field allows 
some tasks to keep a large sun share. A value of zero 


defaults to the system calculated minimum. 
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Figure 14 Bl. (CONTINUED) 
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Figure 14 B2. NEW IBM Research Schedule Table 
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Figure 14 B2. (CONTINUED) 
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Figure 14 B3. Test 4 (Run .5) Schedule Table Modifications 
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Figure 14 B4. Test 5 - Schedule Table Modifications 
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